The Internet (and related networks) can be used to send e-mails, conduct business, automate machinery and used for data processing. Connected users can use the Internet to interact with other connected users and/or connected computer systems. One such interaction is a web browser (an example of a web client) and web server interacting.
In a simple use of the Internet, a web browser running on a computer connected to the Internet makes a request directed at a web server that is connected to the Internet. Assuming that the web server has the requested page and the web server determined that the requested web page is OK to send, the web server responds to the web browser with the requested web page. If the web server is programmed to allow any requester to access a copy of any web page on the web server, security is simple. The web server just checks whether the request includes the exact URL of a page that web server has. For some uses, that is sufficient. As complexity of web services has expanded, web servers are often expected to do more, such as serving dynamic pages, e.g., web page content that is compiled or generated after the request is received.
Dynamic pages are useful, such as for a query-response scenario, wherein the URL submitted by a web browser in an HTTP request is not for a static, pre-existing page, but is a URL that encodes data, using “<FORM>” fields or other protocols, where the data is intended to be processed by the web server. For example, a web browser might send an HTTP request that essentially says “Please query the personnel directory and return me a list of all of the employees that match the query ‘lastname=S*’”. Upon receipt, the web server might submit the query string to a database management server back end, wait for the response, format the database response into a HyperText Markup Language (“HTML”) page and return that to the requesting web browser.
If that was all that the web server could do, and the personnel list was public, it might not matter what requests are sent and by what computers or web browsers. However, the typical web service configuration might be more complicated. For example, the database might respond to harmful queries and cause data breaches, data loss or other ill effects. In such cases, it might be possible for a web browser (or a computer program programmed by an attacker for exactly this purpose) to send a malformed request to the web server that the server would then pass to the database management system that would return to the web browser all of the data in the database, modify data, destroy data in the database, or perform other malicious operations.
Often, these types of attacks are referred to as “code injection” attacks. In a code injection attack, a secured system expects data (strings, queries, structured data, URLs, etc.) that inform the secured system about a request being made. When data that is received is in the expected form, the secured system executes programs that are intended to process valid requests. However, when an attacker submits a request that is not in the normal form, has escape sequences, command statements, or other features, that request might have an effect of running program code designed for the attacker's benefit rather than subject to the constraints intended by the secured system designers. One way to view these actions is that the attacker is using a data submission mechanism to inject program code that the attacker wants run and perhaps the designers of the secured system did not intend to be allowable.
Code injection is known and barriers to code injection are also known. For example, submitting the string ‘“OR ‘1’=’1” as part of a password entry can result in a reply that contains an entire secured database. As a result, many secured systems will have a parser or filter that would drop requests that use single quotes as part of their data, or would at least filter those out. Unfortunately, attackers know this and will try and exploit this vulnerability in unpatched servers or try other escape sequences or code injection avenues. This constant one-upmanship keeps server security and administrators busy. Not only do they have to maintain their systems, they also have to apply patches to complex systems and keep up with new modes of attack as they come up.
Improved security methods and apparatus could be used to ease this burden.